Developing UPPAAL over 15 years

Uppaal is a tool suitable for model checking real-time systems described as networks of timed automata communicating by channel synchronizations and extended with integer variables. Its first version was released in 1995 and its development is still very active. It now features an advanced modelling language, a user-friendly graphical interface, and a performant model checker engine. In addition, several flavors of the tool have matured in recent years. In this paper, we present how we managed to maintain the tool during 15 years, its current architecture with its challenges, and we give future directions of the tool. 1 Development History Uppaal is first of all a research tool born from the collaboration of Uppsala and Aalborg universities [24]. Its theory comes from [1] with decidability results based on regions. Its performance originally comes from zones [18] as a representation for states. Since then the development has been fuelled by scientific results on algorithms or new data structures such as [4,5,6,9,19,20] and very importantly by case studies that pushed us to push the limits of the tool, such as [7,10,11,21,22]. On the other hand, having such a tool helps to develop and test new theories and algorithms, which has given us a synergy during the last decade between tool development and publications. Recently, the tool has blossomed into several domain specific versions, namely, Cora [5] (cost-optimal reachability), Tron [17] (online testing), CoVer [15,16] (coverage testing), Tiga [3] (timed game solver), Port [13,14] (component based), Pro (extension with probabilities, in progress), andTimes [12,2] (scheduling and analysis). These extensions are made based on a common code base, re-using basic data structures to represent states, store them, and perform some basic computations. How have we managed to get going for 15 year across different physical sites with changing teams? The first reason is our commitment to have an efficient tool implementing our research results. A tool strengthens and sometimes disprove theories. Second, we use a centralized version management system (cvs and then subversion), which allows distributed teams to work on the same code. A given checkout of the repository contains all variants of the tool but they all live in their own separated modules. Developers are responsible for few modules and modify other modules occasionally only. Finally, we are using a bug management system (bugzilla) and we do regression testing. We update our battery of tests with examples that trigger new bugs. To find which changes in the repository history trigger a new bug, we use binary search on the revision numbers until we find a revision n where the bug is not present and a revision n + 1 where it is present. This is a very effective technique. In the long term, the code base goes through different life cycles. The first cycle was with the original atg graph editor and an early custom simulator. The second introduced an integrated graphical editor, the client-server architecture still in use today, and an improved engine. The third cycle is the current one with a modular pipeline architecture. The development is incremental during a cycle, following the current design and making changes until the amount of desired features and new algorithms reaches a threshold. Then there is a major effort to re-design or re-factor the code and we continue. The current architecture has lived up to its expectations for approximately 8 years, during which we could re-use existing components and create new ones that we could litteraly plug together. However, now is the time for a major update. 2 Current Architecture Overview Uppaal is based on a client-server architecture with the graphical interface (client) communicating with the model checker (server) via a local pipe or the network. This separation of concerns makes Uppaal easier to port and maintain on different platforms. The model checker itself is designed around PWList Transition Successor Delay Extrapolation Initial state Fig. 1. Simplified pipeline architecture. a pipeline architecture [4] where each block or filter processes states and sends them to the next stage as shown in Fig. 1. The different stages include, e.g., delay, extrapolation, or storing states. Typically the reachability analysis pipeline has a while loop taking states from our (unified) passed and waiting list structure and explores them by pushing them to the first filter. The chain is Transition (which transitions can be taken) Successor (execution of the transitions) Delay (let time pass) Extrapolation (apply an appropriate extrapolation to ensure finite exploration) PWList (inclusion check and mark the state to be explored) Query (evaluate the formula if the state was not included). Implementing another checker, e.g. a timed game solver, is relatively easy and consists in adding components that will do the backward propagation, changing the first filter to either explore forward or backward, add a post-processing filter to detect what is winning or losing in the game after Extrapolation, and changing the graph representation. To change the semantics of the game, e.g. to implement simulation checking [8], mainly consists in changing Transition that implements the transition relation and changing Delay to allow turn-based delay. In addition to these components, Uppaal contains a virtual machine to execute the compiled byte-code of our C-like input language supporting user defined functions and types. This is abstracted in the form of Expression objects that we can re-use across different flavours of Uppaal, which makes other extensions such as adding probabilities easier. We currently distribute some open source components, such as the parser and the difference bound matrix (DBM) library. The parser understands the XML format we use in Uppaal, which allows other researchers to use the same format. The DBM library handles DBMs and federations (unions of DBMs) used to represent symbolic states. The DBM library supports a wide range of operations including subtractions and merging of DBMs.